IBIS Macromodel Task Group Meeting date: 19 December 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Mike LaBonte. Curtis Clark took the minutes. Arpad Muranyi was on the call, but he was traveling so Mike ran the meeting. -------------------------------------------------------------------------------- Opens: - Mike reviewed the schedule for upcoming ATM meetings. ATM meetings will not be held on December 26, 2017 and January 2, 2018. The next ATM meeting will occur on January 9, 2018. ------------- Review of ARs: - Walter to send BIRD189 draft12_v1 and his latest proposal to the ATM and Interconnect lists. - Done. - Mike L. to post them to the Interconnect archives as BIRD189 draft12 and draft13 respectively. - Done. Walter noted that he had subsequently sent out a draft13.1 after the Wednesday Interconnect meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Mike L.: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Michael M.: Second. - Mike L.: Anyone opposed? [none] ------------- New Discussion: Forward Error Correction: - Mike L.: I proposed this topic for discussion, but I'd prefer to defer it as long as any BIRD189 issues are outstanding. - Walter: I don't think we need to consider it. - FEC determines the bit pattern stimulus. - We don't care about that. We only care about what physically goes down the channel. - Whether it's 8b/10b or 64b/66b or some FEC pattern, IBIS and IBIS-AMI don't care about it at all. [further discussion deferred so we can focus on BIRD189] BIRD189 - Groups/Sets, Aggressor treatment. - Mike L.: During the last interconnect meeting I hastily drew up a graphic I think might be useful for the Aggressors discussion. - [Sharing his graphic] (a crude ASCII representation is shown below) Illustration - 8 Pin Component: | | | | | | | | 1 2 3 4 5 6 7 8 Model 1 (first 3 pins - pins 1,2,3): v v A | | | | | | | | 1 2 3 4 5 6 7 8 Model 2 (pins 2, 3, 4): A v A | | | | | | | | 1 2 3 4 5 6 7 8 Model 3 (pins 3, 4, 5): A v A | | | | | | | | 1 2 3 4 5 6 7 8 v - victim A - Aggressor_Only - Mike L.: Do people think the BIRD would be helped by a visual like this for the Aggressor_Only topic? - Walter: Yes, this is worth discussing. - Mike L: It may look a bit like swathing, but it's not. The intent is to show 3 models covering 3 different sets of pins. - These examples are just worried about nearest-neighbor crosstalk. - Michael M: I'd like to confirm that for the purposes of this example the 8 pin illustration represents the entire device, right? - Curtis: This point is important because pin 1 in Model 1 might not necessarily be shown as a victim if there were potentially a pin 0 to the left of it. Is that what you're getting at? - Michael M: Exactly. - Walter: I'd suggest Mike add a box around the top block of 8 pins that indicates that it represents the whole Component. - The three models shown could be in one Set included in one Group. That would likely be the most logical way of packaging these models. - This graphic could be very useful for illustrating the various combinations of victim and aggressor. - For example, let's assume Model 2 were removed from the figure and only Model 1 and Model 3 remained: - In that case, pin 3 would never appear as a victim and would appear in two models as Aggressor_Only. This could help illustrate the point of a new rule I added to address this situation, which was raised by Arpad. - In addition, pin 5 would never appear as a victim and would appear in only one model as Aggressor_Only. - Randy: The new rule you added says that if the user tried to simulate pin 3 as a victim in this scenario, then to find a model for it you'd use the first model in the list that contains pin 3, right? - Walter: Yes. Model 1 in this case. My new text says the "model maker shall assume" that the first model will be used. The tool or user could choose to select a different one. - Walter/Randy: Of course it wouldn't make much sense for a model maker to deliver a BIRD189 model that doesn't have every meaningful pin listed as a victim somewhere. - Michael M.: The way we might do this is to release a model that looks like Model 2 in this example. We would say it represents the worst- case crosstalk that is likely to be seen for this particular collection of pins. We'd primarily only be interested in what's going on in the center pin (or typically a center diff pin pair). - Walter: That's a classic way to distribute a coupled package model. - They might deliver a separate s2p for each pin for the single ended example in this illustration. (an s4p for each pair if it were differential) - They do this because the length of the interconnect might differ for each pin, and small differences in that length can dramatically affect the channel performance. - Then they'll deliver an s2p for the worst-case crosstalk. This allows the EDA tool to build the worst-case coupled model because it knows the through path and the worst-case crosstalk. - Another option would be that if you provide a model like Model 2 for the worst-case crosstalk for a particular collection of pins, then the EDA tool could go ahead and apply that same model for every victim pin of that type (apply the same model for 1,2,3 and 2,3,4 and 3,4,5 etc.) - This is more of a pre-layout way of distributing models. - IBIS is describing a [Component] generally, and you'd be providing an IBIS component that is really just for this 3 pin worst-case. - For our internal tools I might even take that 3 pin Model, say it's for a worst-case DQ crosstalk, and apply it for all the DQ lines. That way you wouldn't even have to go and duplicate the same model in multiple instances. That was a sort of pre-layout scenario we originally had in BIRD189, where we had the model name associated with the pin. We took that out for other reasons. - Discussion: Bob expressed some concern that for the sake of completeness we might want to show some Vdd and Vss pins and include PDN modeling aspects in the graphic. Walter said we could do this, at the expense of complicating the example, but that the current illustration was primarily for discussion of the Aggressor_Only tag. Bob suggested that for differential examples we might want to state that both pins in a differential pair should have the same Aggressor_Only (or victim) designation. Walter agreed that we might say Aggressor_Only on a pin applies to the pad and buffer as well and also applies to the other pin of a diff pin pair. Bob suggested that he wanted a statement that we allow interconnect models in which no pin is tagged as Aggressor_Only. He said the EDA tool should be capable of making decisions about what to include in a simulation. Mike L. noted that Bob was reaffirming that Aggressor_Only is optional, but said the purpose is to give the model maker a way to flag the limitations of the model if necessary. Walter noted that the EDA tool can always do what it wants to do. The Aggressor_Only flag is simply recognizing that sometimes you cannot make a model where every pin has all of its aggressor information. You need a way of indicating when you have a model in which certain pins do not have all their aggressor information. Bob suggested that at the following Interconnect meeting we review a BGA package model diagram Randy had presented and discussed in the August 10, 2016 Interconnect meeting. He felt it would be useful to revisit it in light of these discussions. - Arpad: Thank you all for joining. Happy New Year. ------------- Next meeting: 9 January 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives